Information technology (“IT”) administrators have used personal computer (“PC”) imaging tools, such as Ghost® of Symantec, Inc., to create and deploy configurations of these computers called “Golden Images.” Deploying a “Golden Image” to a PC makes that PC's system substantially identical to the ideal configuration in terms of applications, settings, drivers, etc. These Golden Images can be deployed to thousands of PCs in a matter of minutes, eliminating the need to manually configure each machine individually, which provides a substantial savings in time and labor. Further, when there is the manual configuration of a number of PCs, it introduces the risk for variations and errors, leading to slight variations in the behavior of such PCs on which mistakes are made or configuration steps are missed or improperly applied.
Deploying custom “Golden Images” to mobile smart devices, such as smart phones, cannot be performed in the traditional manner used for PCs because of advancements and alterations in many of the security techniques applicable to mobile smart devices. For the purposes of the present invention, “smart devices” include, but is not limited to, smart phones, tablet devices, personal digital assistants (“PDAs”), etc., hereinafter collectively referred to as “smart devices.”
As the distribution and provisioning of smart devices becomes increasingly prevalent in the government and commercial sectors, organizational rollouts may necessitate numerous standardized configuration steps between factory builds and end-user delivery. In this context, large-scale smart device configuration becomes a significant investment. Currently, there exists no smart device equivalent for Symantec's Ghost® to establish baseline configurations for Android-based systems, and up to 75% of mobile security breaches result from basic misconfiguration.
There are three primary obstacles that make the translation of Symantec Ghost®-esque tools to Android-based small device systems difficult. First, the Android Operating System (“OS”) architecture substantially prevents direct access to persistent memory storage (“Flash” memory) and does not provide a mechanism to reboot smart devices into a mode that would allow IT administrators to directly write applications, configure systems, or input data onto a large number of devices simultaneously. Second, Android-based application storage mechanisms are not standardized and absent such standardization across Android applications, IT administrators cannot reliably determine how to automate the insertion of data to configure the applications. This applies since the inaccessibility of persistent memory storage may be circumvented by inserting data into pre-determined locations in application folders. Third, manufacturers and carriers may exert certain controls over smart device OSs that rigorously structure the method by which Android systems can be configured. Any technique seeking to create a common configuration across multiple devices has to work within the confines of running OSs and the prescribed mechanisms for configuring/altering the smart devices.
At present, smart device configuration is executed either manually or with partially automated (“pre-staging”) by IT administrators, integrators, carriers, or equipment manufacturers. Combining setup steps and corporate data, such as usernames, email addresses, and passwords, along with quality assurance and testing may require from several minutes per device to over an hour of smart device processing time. Therefore, if an enterprise with hundreds or thousands of smart devices is forced to configure them, it may be required to devote weeks or months of man-hours to the manual setup and data entry, while incurring the rollout risk of erroneous configurations, help-desk calls, and re-working. This same type of manual activity is required to conduct compliance checks and IT audits, which often require active insight into baseline configurations of enterprise devices. Absent an automated and remote method of assuring that a number of smart devices are in compliance with designated configurations, IT administrators are required to physically inspect each smart device during an IT audit.
Currently there is existing technology that attempts to address these challenges. This technology is primarily directed to services known as Mobile Device Management (“MDM” services. These services are also referred to as Enterprise Mobility Management or Mobile Application Management Services. MDM products primarily focus on the active management of devices rather than their initial configuration. The techniques of these products typically have limited configuration capabilities, including VPN setup, application installation, and allowing or disallowing installation of applications from unknown sources. Examples of such services include Mobilelron, Inc. See, U.S. Pat. No. 8,359,016, titled “Management of Mobile Applications,” U.S. Pat. No. 8,695,058, titled “Selective Management of Mobile Device Data in an Enterprise Environment,” and U.S. Pat. No. 8,862,105, titled “Management of Mobile Applications.” There is also, the services of Good Technology, Inc. that provide these limited services. See, U.S. Pat. No. 6,151,606, titled “System and Method for Using a Workspace Data Manager to Access, Manipulate, and Synchronize Network Data,” U.S. Pat. No. 7,970,386, titled “System and Method for Monitoring and Maintaining a Wireless Device”; and U.S. Pat. No. 7,702,322, titled “Method and System for Distributing and Updating Software in Wireless Devices.”
In the smart device configuration environment, MDM suites are limited to exclusively programmatic methods of configuring devices, i.e., executing some subset of the application program interface (“API”) calls already programmed into the device's capabilities. This limitation relating to programmatic configuration is that not all device or application settings are accessible through exclusively programmatic methods, especially third-party applications that are not integrated with the APIs. Therefore, unless there is specific support built into the Android-based OS or other OS for an API call to perform an action and the MDM service supports that API call, MDMs are not capable of executing that action or affect any associated settings or configurations whether they are Android settings, native application configurations, third-party application configurations, or user-specific data fields. As a result, a significant number of smart device configuration steps require input through human touch interaction with the device rather than programmatic interaction using APIs.
An alternative technology to MDM services that has been applied to the field of mobile device configuration is a USB-facilitated solution termed “Rubber Ducky.” While such a usage is a significant divergence from the intended use of Rubber Ducky, which is described as a keystroke injection attack platform, Rubber Ducky may be used to execute programs on smart devices by acting as a surrogate keyboard interface through the ubiquitous human interface device (“HID”) USB standard. While only limited configuration of smart devices in this manner may be possible, implementation is neither feasible nor likely to succeed, and the manipulation of smart devices would be limited to only such actions as can be executed through keyboard interaction.
While existing MDM services and tools to interface with smart devices may be suitable for their particular designed purpose, there are presently no systems capable of universally manipulating smart devices on a large scale through both programmatic interaction and simulations of traditional human touch interaction with a device. Further, there is no element that presently exists that is capable of assuring compliance with IT audits or device compliance checks by remotely re-configuring a large number of smart devices to the desired baseline configuration. There is a need for systems and methods to overcome these problems.